CORS atmaskošana: padziļināta izpēte par JavaScript sākotnējo pieprasījumu apstrādi

Nepārtraukti augošajā tīmekļa izstrādes pasaulē drošība ir vissvarīgākā. Dažādu izcelsmju resursu koplietošana (CORS) ir būtisks drošības mehānisms, ko īsteno tīmekļa pārlūkprogrammas, lai ierobežotu tīmekļa lapas veikt pieprasījumus uz citu domēnu, nevis to, kas apkalpoja tīmekļa lapu. Tā ir fundamentāla drošības funkcija, kas paredzēta, lai novērstu ļaunprātīgu vietņu piekļuvi sensitīviem datiem. Šajā visaptverošajā ceļvedī tiks detalizēti aplūkotas CORS nianses, īpašu uzmanību pievēršot sākotnējo pieprasījumu apstrādei. Mēs izpētīsim CORS 'kāpēc', 'kas' un 'kā', sniedzot praktiskus piemērus un risinājumus bieži sastopamām problēmām, ar kurām saskaras izstrādātāji visā pasaulē.

Izpratne par vienas izcelsmes politiku

CORS pamatā ir Vienas izcelsmes politika (SOP). Šī politika ir pārlūkprogrammas līmeņa drošības mehānisms, kas ierobežo skriptu, kas darbojas vienā izcelsmē, piekļuvi resursiem no citas izcelsmes. Izcelsmi nosaka protokols (piemēram, HTTP vai HTTPS), domēns (piemēram, example.com) un ports (piemēram, 80 vai 443). Diviem URL ir viena izcelsme, ja šie trīs komponenti precīzi sakrīt.

Piemēram:

• https://www.example.com/app1/index.html un https://www.example.com/app2/index.html ir viena izcelsme (viens protokols, domēns un ports).
• https://www.example.com/index.html un http://www.example.com/index.html ir atšķirīgas izcelsmes (atšķirīgi protokoli).
• https://www.example.com/index.html un https://api.example.com/index.html ir atšķirīgas izcelsmes (atšķirīgi apakšdomēni tiek uzskatīti par atšķirīgiem domēniem).
• https://www.example.com:8080/index.html un https://www.example.com/index.html ir atšķirīgas izcelsmes (atšķirīgi porti).

SOP ir izstrādāta, lai novērstu ļaunprātīgu skriptu vienā vietnē piekļuvi sensitīviem datiem, piemēram, sīkfailiem vai lietotāja autentifikācijas informācijai, citā vietnē. Lai gan SOP ir būtiska drošībai, tā var būt arī ierobežojoša, īpaši, ja ir nepieciešami likumīgi starp-izcelsmju pieprasījumi.

Kas ir dažādu izcelsmju resursu koplietošana (CORS)?

CORS ir mehānisms, kas ļauj serveriem norādīt, kurām izcelsmēm (domēniem, shēmām vai portiem) ir atļauts piekļūt to resursiem. Tas būtībā atvieglo SOP, ļaujot kontrolētu starp-izcelsmju piekļuvi. CORS tiek ieviests, izmantojot HTTP galvenes, kas tiek apmainītas starp klientu (parasti tīmekļa pārlūkprogrammu) un serveri.

Kad pārlūkprogramma veic starp-izcelsmju pieprasījumu (t.i., pieprasījumu uz citu izcelsmi nekā pašreizējā lapa), tā vispirms pārbauda, vai serveris atļauj šo pieprasījumu. Tas tiek darīts, pārbaudot Access-Control-Allow-Origin galveni servera atbildē. Ja pieprasījuma izcelsme ir norādīta šajā galvenē (vai ja galvene ir iestatīta uz *, atļaujot visas izcelsmes), pārlūkprogramma atļauj pieprasījuma turpināšanu. Pretējā gadījumā pārlūkprogramma bloķē pieprasījumu, neļaujot JavaScript kodam piekļūt atbildes datiem.

Sākotnējo pieprasījumu loma

Noteiktiem starp-izcelsmju pieprasījumu veidiem pārlūkprogramma iniciē sākotnējo pieprasījumu. Tas ir OPTIONS pieprasījums, kas tiek nosūtīts serverim pirms faktiskā pieprasījuma. Sākotnējā pieprasījuma mērķis ir noteikt, vai serveris ir gatavs pieņemt faktisko pieprasījumu. Serveris atbild uz sākotnējo pieprasījumu ar informāciju par atļautajām metodēm, galvenēm un citiem ierobežojumiem.

Sākotnējie pieprasījumi tiek aktivizēti, ja starp-izcelsmju pieprasījums atbilst jebkuram no šiem nosacījumiem:

• Pieprasījuma metode nav GET, HEAD vai POST.
• Pieprasījums ietver pielāgotas galvenes (t.i., galvenes, kas nav tās, kuras pārlūkprogramma pievieno automātiski).
• Galvene Content-Type ir iestatīta uz jebko citu, izņemot application/x-www-form-urlencoded, multipart/form-data vai text/plain.
• Pieprasījums izmanto ReadableStream objektus ķermenī.

Piemēram, PUT pieprasījums ar Content-Type application/json aktivizēs sākotnējo pieprasījumu, jo tas izmanto citu metodi nekā atļautās un potenciāli neatļautu satura tipu.

Kāpēc sākotnējie pieprasījumi?

Sākotnējie pieprasījumi ir būtiski drošībai, jo tie dod serverim iespēju noraidīt potenciāli kaitīgus starp-izcelsmju pieprasījumus, pirms tie tiek izpildīti. Bez sākotnējiem pieprasījumiem ļaunprātīga vietne varētu potenciāli nosūtīt patvaļīgus pieprasījumus serverim bez servera skaidras piekrišanas. Sākotnējais pieprasījums ļauj serverim apstiprināt, ka pieprasījums ir pieņemams, un novērš potenciāli kaitīgas darbības.

Sākotnējo pieprasījumu apstrāde servera pusē

Pareiza sākotnējo pieprasījumu apstrāde ir būtiska, lai nodrošinātu, ka jūsu tīmekļa lietojumprogramma darbojas pareizi un droši. Serverim ir jāatbild uz OPTIONS pieprasījumu ar atbilstošām CORS galvenēm, lai norādītu, vai faktiskais pieprasījums ir atļauts.

Šeit ir galveno CORS galveņu sadalījums, kas tiek izmantotas sākotnējās atbildēs:

• Access-Control-Allow-Origin: Šī galvene norāda izcelsmi(-es), kurām ir atļauts piekļūt resursam. To var iestatīt uz konkrētu izcelsmi (piemēram, https://www.example.com) vai uz *, lai atļautu visas izcelsmes. Tomēr, izmantot * parasti nav ieteicams drošības apsvērumu dēļ, īpaši, ja serveris apstrādā sensitīvus datus.
• Access-Control-Allow-Methods: Šī galvene norāda HTTP metodes, kas ir atļautas starp-izcelsmju pieprasījumam (piemēram, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers: Šī galvene norāda nestandarta HTTP galveņu sarakstu, kas ir atļautas faktiskajā pieprasījumā. Tas ir nepieciešams, ja klients sūta pielāgotas galvenes, piemēram, X-Custom-Header vai Authorization.
• Access-Control-Allow-Credentials: Šī galvene norāda, vai faktiskais pieprasījums var ietvert akreditācijas datus, piemēram, sīkfailus vai autorizācijas galvenes. Tai jābūt iestatītai uz true, ja klienta puses kods sūta akreditācijas datus un serverim tie būtu jāpieņem. Piezīme: kad šī galvene ir iestatīta uz `true`, `Access-Control-Allow-Origin` *nevar* būt iestatīta uz `*`. Jums ir jānorāda izcelsme.
• Access-Control-Max-Age: Šī galvene norāda maksimālo laiku (sekundēs), cik ilgi pārlūkprogramma var kešot sākotnējo atbildi. Tas var palīdzēt uzlabot veiktspēju, samazinot nosūtīto sākotnējo pieprasījumu skaitu.

Piemērs: Sākotnējo pieprasījumu apstrāde Node.js ar Express

Šeit ir piemērs, kā apstrādāt sākotnējos pieprasījumus Node.js lietojumprogrammā, izmantojot Express ietvaru:

const express = require('express');
const cors = require('cors');
const app = express();

// Iespējot CORS visām izcelsmēm (tikai izstrādes nolūkiem!)
// Ražošanas vidē norādiet atļautās izcelsmes labākai drošībai.
app.use(cors()); //vai app.use(cors({origin: 'https://www.example.com'}));

// Maršruts OPTIONS pieprasījumu (sākotnējo) apstrādei
app.options('/data', cors()); // Iespējot CORS vienam maršrutam. Vai norādīt izcelsmi: cors({origin: 'https://www.example.com'})

// Maršruts GET pieprasījumu apstrādei
app.get('/data', (req, res) => {
  res.json({ message: 'Šie ir starp-izcelsmju dati!' });
});


// Maršruts, lai apstrādātu sākotnējo un post pieprasījumu
app.options('/resource', cors()); // iespējot sākotnējo pieprasījumu DELETE pieprasījumam
app.delete('/resource', cors(), (req, res, next) => {
  res.send('dzēst resursu')
})


const port = 3000;
app.listen(port, () => {
  console.log(`Serveris klausās portā ${port}`);
});

Šajā piemērā mēs izmantojam cors starpprogrammatūru, lai apstrādātu CORS pieprasījumus. Lai iegūtu detalizētāku kontroli, CORS var iespējot katram maršrutam atsevišķi. Piezīme: ražošanas vidē ir stingri ieteicams norādīt atļautās izcelsmes, izmantojot origin opciju, nevis atļaujot visas izcelsmes. Atļaujot visas izcelsmes, izmantojot *, jūsu lietojumprogramma var tikt pakļauta drošības ievainojamībām.

Piemērs: Sākotnējo pieprasījumu apstrāde Python ar Flask

Šeit ir piemērs, kā apstrādāt sākotnējos pieprasījumus Python lietojumprogrammā, izmantojot Flask ietvaru un flask_cors paplašinājumu:

from flask import Flask, jsonify
from flask_cors import CORS, cross_origin

app = Flask(__name__)
CORS(app)  # Iespējot CORS visiem maršrutiem

@app.route('/data')
@cross_origin()
def get_data():
    data = {"message": "Šie ir starp-izcelsmju dati!"}
    return jsonify(data)

if __name__ == '__main__':
    app.run(debug=True)

Šis ir vienkāršākais lietojums. Kā iepriekš, izcelsmes var ierobežot. Sīkāku informāciju skatiet flask-cors dokumentācijā.

Piemērs: Sākotnējo pieprasījumu apstrāde Java ar Spring Boot

Šeit ir piemērs, kā apstrādāt sākotnējos pieprasījumus Java lietojumprogrammā, izmantojot Spring Boot:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@SpringBootApplication
public class CorsApplication {

    public static void main(String[] args) {
        SpringApplication.run(CorsApplication.class, args);
    }

    @Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            @Override
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/data").allowedOrigins("http://localhost:8080");
            }
        };
    }
}

Un atbilstošais kontrolieris:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DataController {

    @GetMapping("/data")
    public String getData() {
        return "Šie ir starp-izcelsmju dati!";
    }
}

Biežākās CORS problēmas un risinājumi

Neskatoties uz tā nozīmīgumu, CORS bieži vien var radīt frustrāciju izstrādātājiem. Šeit ir dažas bieži sastopamas CORS problēmas un to risinājumi:

1. Kļūda: "No 'Access-Control-Allow-Origin' header is present on the requested resource."

   Šī kļūda norāda, ka serveris neatgriež Access-Control-Allow-Origin galveni savā atbildē. Lai to labotu, pārliecinieties, ka serveris ir konfigurēts, lai iekļautu šo galveni un ka tā ir iestatīta uz pareizo izcelsmi vai * (ja piemēroti).

   Risinājums: Konfigurējiet serveri, lai tā atbildē iekļautu `Access-Control-Allow-Origin` galveni, iestatot to uz pieprasītāja vietnes izcelsmi vai `*`, lai atļautu visas izcelsmes (lietot ar piesardzību).

2. Kļūda: "Response to preflight request doesn't pass access control check: Request header field X-Custom-Header is not allowed by Access-Control-Allow-Headers in preflight response."

   Šī kļūda norāda, ka serveris neatļauj pielāgoto galveni (šajā piemērā X-Custom-Header) starp-izcelsmju pieprasījumā. Lai to labotu, pārliecinieties, ka serveris iekļauj šo galveni Access-Control-Allow-Headers galvenē sākotnējā atbildē.

   Risinājums: Pievienojiet pielāgoto galveni (piem., `X-Custom-Header`) `Access-Control-Allow-Headers` galvenei servera sākotnējā atbildē.

3. Kļūda: "Credentials flag is 'true', but the 'Access-Control-Allow-Origin' header is '*'."

   Kad Access-Control-Allow-Credentials galvene ir iestatīta uz true, Access-Control-Allow-Origin galvenei jābūt iestatītai uz konkrētu izcelsmi, nevis *. Tas ir tāpēc, ka akreditācijas datu atļaušana no visām izcelsmēm būtu drošības risks.

   Risinājums: Lietojot akreditācijas datus, iestatiet `Access-Control-Allow-Origin` uz konkrētu izcelsmi, nevis `*`.

4. Sākotnējais pieprasījums netiek nosūtīts.

   Rūpīgi pārbaudiet, vai jūsu Javascript kods ietver `credentials: 'include'` īpašību. Pārbaudiet arī, vai jūsu serveris atļauj `Access-Control-Allow-Credentials: true`.

5. Pretrunīgas konfigurācijas starp serveri un klientu.

   Rūpīgi pārbaudiet savu servera puses CORS konfigurāciju kopā ar klienta puses iestatījumiem. Neatbilstības (piemēram, serveris atļauj tikai GET pieprasījumus, bet klients sūta POST) izraisīs CORS kļūdas.

CORS un drošības labākās prakses

Lai gan CORS nodrošina kontrolētu starp-izcelsmju piekļuvi, ir svarīgi ievērot drošības labākās prakses, lai novērstu ievainojamības:

• Ražošanas vidē izvairieties no * izmantošanas Access-Control-Allow-Origin galvenē. Tas ļauj visām izcelsmēm piekļūt jūsu resursiem, kas var radīt drošības risku. Tā vietā norādiet precīzas atļautās izcelsmes.
• Rūpīgi apsveriet, kuras metodes un galvenes atļaut. Atļaujiet tikai tās metodes un galvenes, kas ir stingri nepieciešamas jūsu lietojumprogrammas pareizai darbībai.
• Ieviesiet pareizus autentifikācijas un autorizācijas mehānismus. CORS neaizstāj autentifikāciju un autorizāciju. Pārliecinieties, ka jūsu API ir aizsargāts ar atbilstošiem drošības pasākumiem.
• Validējiet un sanitizējiet visus lietotāja ievaddatus. Tas palīdz novērst starpvietņu skriptošanas (XSS) uzbrukumus un citas ievainojamības.
• Atjauniniet savu servera puses CORS konfigurāciju. Regulāri pārskatiet un atjauniniet savu CORS konfigurāciju, lai nodrošinātu, ka tā atbilst jūsu lietojumprogrammas drošības prasībām.

CORS dažādās izstrādes vidēs

CORS problēmas var izpausties atšķirīgi dažādās izstrādes vidēs un tehnoloģijās. Šeit ir apskatīts, kā pieiet CORS dažos izplatītos scenārijos:

Vietējās izstrādes vides

Vietējās izstrādes laikā CORS problēmas var būt īpaši kaitinošas. Pārlūkprogrammas bieži bloķē pieprasījumus no jūsu vietējā izstrādes servera (piemēram, localhost:3000) uz attālinātu API. Vairākas metodes var atvieglot šo problēmu:

• Pārlūkprogrammas paplašinājumi: Paplašinājumi, piemēram, "Allow CORS: Access-Control-Allow-Origin", var īslaicīgi atspējot CORS ierobežojumus testēšanas nolūkiem. Tomēr *nekad* neizmantojiet tos ražošanas vidē.
• Starpniekserveri (Proxy): Konfigurējiet starpniekserveri, kas pārsūta pieprasījumus no jūsu vietējā izstrādes servera uz attālinātu API. Tas efektīvi padara pieprasījumus par "vienas izcelsmes" no pārlūkprogrammas viedokļa. Šim nolūkam noderīgi ir rīki, piemēram, http-proxy-middleware (Node.js).
• Konfigurēt servera CORS: Pat izstrādes laikā ir laba prakse konfigurēt savu API serveri, lai tas skaidri atļautu pieprasījumus no jūsu vietējās izstrādes izcelsmes (piemēram, http://localhost:3000). Tas simulē reālu CORS konfigurāciju un palīdz agrīni atklāt problēmas.

Bezservera vides (piem., AWS Lambda, Google Cloud Functions)

Bezservera funkcijām bieži nepieciešama rūpīga CORS konfigurācija. Daudzas bezservera platformas nodrošina iebūvētu CORS atbalstu, taču ir svarīgi to pareizi konfigurēt:

• Platformai specifiski iestatījumi: Izmantojiet platformas iebūvētās CORS konfigurācijas opcijas. Piemēram, AWS Lambda ļauj norādīt atļautās izcelsmes, metodes un galvenes tieši API Gateway iestatījumos.
• Starpprogrammatūra/Bibliotēkas: Lielākai elastībai varat izmantot starpprogrammatūru vai bibliotēkas, lai apstrādātu CORS savā bezservera funkcijas kodā. Tas ir līdzīgi pieejām, kas tiek izmantotas tradicionālajās serveru vidēs (piemēram, izmantojot `cors` pakotni Node.js Lambda funkcijās).
• Apsveriet OPTIONS metodi: Pārliecinieties, ka jūsu bezservera funkcija pareizi apstrādā OPTIONS pieprasījumus. Tas bieži ietver atsevišķa maršruta izveidi, kas atgriež atbilstošās CORS galvenes.

Mobilo lietotņu izstrāde (piem., React Native, Flutter)

CORS nav tik tieša problēma vietējām mobilajām lietotnēm (Android, iOS), jo tās parasti nepiemēro vienas izcelsmes politiku tāpat kā tīmekļa pārlūkprogrammas. Tomēr CORS joprojām var būt aktuāls, ja jūsu mobilā lietotne izmanto tīmekļa skatu, lai attēlotu tīmekļa saturu, vai ja izmantojat tādus ietvarus kā React Native vai Flutter, kas izmanto JavaScript:

• Tīmekļa skati: Ja jūsu mobilā lietotne izmanto tīmekļa skatu, lai attēlotu tīmekļa saturu, tiek piemēroti tie paši CORS noteikumi kā tīmekļa pārlūkprogrammā. Konfigurējiet savu serveri, lai atļautu pieprasījumus no tīmekļa satura izcelsmes.
• React Native/Flutter: Šie ietvari izmanto JavaScript, lai veiktu API pieprasījumus. Lai gan vietējā vide var tieši nepiemērot CORS, pamatā esošie HTTP klienti (piemēram, fetch) noteiktās situācijās joprojām var uzrādīt CORS līdzīgu uzvedību.
• Vietējie HTTP klienti: Veicot API pieprasījumus tieši no vietējā koda (piemēram, izmantojot OkHttp Android vai URLSession iOS), CORS parasti nav faktors. Tomēr jums joprojām ir jāapsver drošības labākās prakses, piemēram, pareiza autentifikācija un autorizācija.

Globāli apsvērumi CORS konfigurācijai

Konfigurējot CORS globāli pieejamai lietojumprogrammai, ir svarīgi ņemt vērā tādus faktorus kā:

• Datu suverenitāte: Noteikumi dažos reģionos nosaka, ka datiem jāatrodas reģiona robežās. CORS var būt iesaistīts, piekļūstot resursiem pāri robežām, potenciāli pārkāpjot datu rezidences likumus.
• Reģionālās drošības politikas: Dažādās valstīs var būt atšķirīgi kiberdrošības noteikumi un vadlīnijas, kas ietekmē, kā CORS būtu jāievieš un jānodrošina.
• Satura piegādes tīkli (CDN): Pārliecinieties, ka jūsu CDN ir pareizi konfigurēts, lai pārsūtītu nepieciešamās CORS galvenes. Nepareizi konfigurēti CDN var noņemt CORS galvenes, izraisot negaidītas kļūdas.
• Slodzes līdzsvarotāji un starpniekserveri: Pārbaudiet, vai jebkuri slodzes līdzsvarotāji vai reversie starpniekserveri jūsu infrastruktūrā pareizi apstrādā sākotnējos pieprasījumus un pārsūta CORS galvenes.
• Daudzvalodu atbalsts: Apsveriet, kā CORS mijiedarbojas ar jūsu lietojumprogrammas internacionalizācijas (i18n) un lokalizācijas (l10n) stratēģijām. Pārliecinieties, ka CORS politikas ir konsekventas dažādās jūsu lietojumprogrammas valodu versijās.

CORS testēšana un atkļūdošana

Efektīva CORS testēšana un atkļūdošana ir ļoti svarīga. Šeit ir dažas metodes:

• Pārlūkprogrammas izstrādātāja rīki: Pārlūkprogrammas izstrādātāja konsole ir jūsu pirmais pieturas punkts. Cilnē "Network" (Tīkls) tiks parādīti sākotnējie pieprasījumi un atbildes, atklājot, vai CORS galvenes ir klāt un pareizi konfigurētas.
• `curl` komandrindas rīks: Izmantojiet `curl -v -X OPTIONS `, lai manuāli nosūtītu sākotnējos pieprasījumus un pārbaudītu servera atbildes galvenes.
• Tiešsaistes CORS pārbaudītāji: Daudzi tiešsaistes rīki var palīdzēt validēt jūsu CORS konfigurāciju. Vienkārši meklējiet "CORS checker".
• Vienību un integrācijas testi: Rakstiet automatizētus testus, lai pārbaudītu, vai jūsu CORS konfigurācija darbojas, kā paredzēts. Šiem testiem jāaptver gan veiksmīgi starp-izcelsmju pieprasījumi, gan scenāriji, kuros CORS būtu jābloķē piekļuve.
• Žurnālēšana un monitorings: Ieviesiet žurnālēšanu, lai sekotu līdzi ar CORS saistītiem notikumiem, piemēram, sākotnējiem pieprasījumiem un bloķētiem pieprasījumiem. Pārraugiet savus žurnālus, lai atklātu aizdomīgas darbības vai konfigurācijas kļūdas.

Nobeigums

Dažādu izcelsmju resursu koplietošana (CORS) ir būtisks drošības mehānisms, kas nodrošina kontrolētu starp-izcelsmju piekļuvi tīmekļa resursiem. Izpratne par to, kā darbojas CORS, īpaši sākotnējie pieprasījumi, ir būtiska, lai veidotu drošas un uzticamas tīmekļa lietojumprogrammas. Ievērojot šajā ceļvedī izklāstītās labākās prakses, jūs varat efektīvi risināt CORS problēmas un aizsargāt savu lietojumprogrammu no potenciālām ievainojamībām. Atcerieties vienmēr piešķirt prioritāti drošībai un rūpīgi apsvērt savas CORS konfigurācijas ietekmi.

Tīmekļa izstrādei attīstoties, CORS joprojām būs kritisks tīmekļa drošības aspekts. Būt informētam par jaunākajām CORS labākajām praksēm un metodēm ir būtiski, lai veidotu drošas un globāli pieejamas tīmekļa lietojumprogrammas.